Le Flipper Zero fait le plein de nouveautés avec son firmware… 1.0

Le Flipper Zero est un petit appareil qui a entamé sa vie sous la forme d’une campagne Kickstarter en 2020. Depuis, il n’a cessé de gagner en popularité. Il permet de cloner des signaux (radio, NFC) et peut effectuer des tests d'intrusion. Mais il peut aussi être utilisé à des fins malveillantes. Au début de l’année, le Brésil avait interdit sa vente et le Canada réfléchissait à faire de même.

Sur son blog, l’équipe en charge du projet annonce la sortie du firmware 1.0. Oui, quatre ans après le début de la campagne et alors que des Flipper Zero sont en vente depuis longtemps maintenant. « Dans cette version, nous avons terminé le travail sur de nombreuses fonctionnalités qui étaient en développement depuis trois ans et qui sont maintenant stables », expliquent les développeurs.

Parmi les nouveautés, il est question du chargement dynamique des applications tierces. Un point important, car il permet de régler le souci de mémoire interne : « Grâce à lui, Flipper Zero est désormais capable d'exécuter des applications directement à partir de fichiers FAP sur la carte microSD (FAP signifie Flipper Application Package) […] Nous pouvons enfin continuer à ajouter de nouvelles fonctionnalités et les stocker en dehors du firmware, économisant ainsi de l'espace sur la mémoire flash du système ».

Signalons aussi un nouveau sous-système NFC « entièrement réécrit » et bien plus rapide, de la prise en charge de JavaScript, etc. « L’autonomie de la batterie atteint un mois en veille. La vitesse de transfert de données Bluetooth avec les appareils Android a été multipliée par deux ». Des améliorations sont aussi présentes sur la prise en charge des protocoles radio, de l’infrarouge… Les notes de version se trouvent par ici.

Commentaires (10)


Je suis surpris de la communication autour du Firmware 1.0 : la grande majorité des fonctionnalités annoncées dans leur article de blog sont disponibles depuis plusieurs mois, si ce n'est pas un an pour certaines 🤔
Modifié le 12/09/2024 à 09h21

Historique des modifications :

Posté le 12/09/2024 à 09h19


Je suis surpris de la communication autour du Firmware 1.0 : la grande majorité des fonctionnalités annoncées dans leur article de blog sont disponibles depuis plusieurs mois, si ce n'est pas un an 🤔

C'est probablement aussi l'occasion de présenter les ajouts "récents" pour tous ceux qui auraient arrêté de jouer avec il y a un moment.

Le milestone 1.0 pourrait pousser des amateurs qui ont arrêté d'utiliser ou de chercher à trouver de nouveaux usages à leur Flipper Zero d'y rejeter un oeil.
Il est tout à fait normal dans la comm d'une version majeure de re-lister l'ensemble des améliorations qu'apporte cette version par rapport à la version majeure précédente. Ca ne se fait juste pas d'obliger les utilisateurs normaux à agréger eux-même les infos des releases notes des version intermédiaires et/ou beta. Même pour un outil comme celui-là.

DetunizedGravity

Il est tout à fait normal dans la comm d'une version majeure de re-lister l'ensemble des améliorations qu'apporte cette version par rapport à la version majeure précédente. Ca ne se fait juste pas d'obliger les utilisateurs normaux à agréger eux-même les infos des releases notes des version intermédiaires et/ou beta. Même pour un outil comme celui-là.
Techniquement, dans les versions 0.x.y, chaque incrément de x est une version majeure :cap:

C'est pour la blague, je rejoins le fond de ta pensée ;)

haelty

Techniquement, dans les versions 0.x.y, chaque incrément de x est une version majeure :cap:

C'est pour la blague, je rejoins le fond de ta pensée ;)
Nope, c'est majeur.mineur.patch
Donc c'est la première version majeure :)

https://semver.org/lang/fr/

Un joli milestone pour ce beau projet !

pofilo

Nope, c'est majeur.mineur.patch
Donc c'est la première version majeure :)

https://semver.org/lang/fr/

Un joli milestone pour ce beau projet !
Je sais bien que ça faisait référence au SemVer ;)

J'ai effectivement fait un abus de langage en parlant des versions 0.x comme majeures. Mais c'est plutôt considéré comme tel dans la pratique. Dans les différents packages managers qui utilisent le semver pour choisir le package le plus récent qui ne casse pas l'API, les changements de numéro mineur dans les versions 0.x.y sont considérés comme des breaking changes. Ils sont donc considéré comme étant des changements de numéro majeures.

D'ailleurs selon le SemVer, l'ajout de fonctionnalités compatibles (ce qui est le cas de la plupart des ajouts sur le Flipper) nécessitent juste un changement de numéro mineur. Du coup, pour documenter les apports de fonctionnalités, il faut considérer la majeure précédente ou la mineure ?

Qu'est-ce qui fait que cette approximation d'associer la documentation d'apport de fonctionnalités sur les majeures (puisque pas compatible avec un semver stricte) serait acceptable, mais mon approximation non ? :D

En vrai, le semver n'a rien à voir avec tout ça. La release 1.0 est un milestone symbolique qui offre une belle opportunité de communication et ils ont bien raison de répéter l'annonce de fonctionnalités qui peuvent intéresser les bidouilleurs!

Et ils doivent même pas forcément être exhaustif, on ne manque pas de respect à ceux qui ont bien raison de pas avoir pris la peine de scruter chaque changelog. Comme expliqué, si une fonctionnalité a déjà été mentionnée dans une mineure précédente Ils ne sont pas obligés de le refaire. Ceux qui sont intéressés d'avoir la liste complète de ce qu'il est possible de faire peuvent aller voir la liste des fonctionnalités actuelles ;)

C'est juste de la communication pour toucher une plus grande audience quoi.

Voilà, sorry pour la boutade en tout cas ;)
Modifié le 13/09/2024 à 02h22

Historique des modifications :

Posté le 13/09/2024 à 02h21


Je sais bien que ça faisait référence au SemVer ;)

J'ai effectivement fait un abus de langage en considérant que dans les différents packages managers qui utilisent le semver pour choisir le package le plus récent qui ne casse pas l'API, les changements de numéro mineur dans les versions 0.x.y sont considérés comme des breaking changes. Ils sont donc considéré comme étant des changements de numéro majeures.

D'ailleurs selon le SemVer, l'ajout de fonctionnalités compatibles (ce qui est le cas de la plupart des ajouts sur le Flipper) nécessitent juste un changement de numéro mineur. Du coup, pour documenter les apports de fonctionnalités, il faut considérer la majeure précédente ou la mineure ?

Qu'est-ce qui fait que cette approximation d'associer la documentation d'apport de fonctionnalités sur les majeures (puisque pas compatible avec un semver stricte) serait acceptable, mais mon approximation non ? :D

En vrai, le semver n'a rien à voir avec tout ça. La release 1.0 est un milestone symbolique qui offre une belle opportunité de communication et ils ont bien raison de répéter l'annonce de fonctionnalités qui peuvent intéresser les bidouilleurs!

Et ils doivent même pas forcément être exhaustif, on ne manque pas de respect à ceux qui ont bien raison de pas avoir pris la peine de scruter chaque changelog. Comme expliqué, si une fonctionnalité a déjà été mentionnée dans une mineure précédente Ils ne sont pas obligés de le refaire. Ceux qui sont intéressés d'avoir la liste complète de ce qu'il est possible de faire peuvent aller voir la liste des fonctionnalités actuelles ;)

C'est juste de la communication pour toucher une plus grande audience quoi.

Voilà, sorry pour la boutade en tout cas ;)

haelty

Je sais bien que ça faisait référence au SemVer ;)

J'ai effectivement fait un abus de langage en parlant des versions 0.x comme majeures. Mais c'est plutôt considéré comme tel dans la pratique. Dans les différents packages managers qui utilisent le semver pour choisir le package le plus récent qui ne casse pas l'API, les changements de numéro mineur dans les versions 0.x.y sont considérés comme des breaking changes. Ils sont donc considéré comme étant des changements de numéro majeures.

D'ailleurs selon le SemVer, l'ajout de fonctionnalités compatibles (ce qui est le cas de la plupart des ajouts sur le Flipper) nécessitent juste un changement de numéro mineur. Du coup, pour documenter les apports de fonctionnalités, il faut considérer la majeure précédente ou la mineure ?

Qu'est-ce qui fait que cette approximation d'associer la documentation d'apport de fonctionnalités sur les majeures (puisque pas compatible avec un semver stricte) serait acceptable, mais mon approximation non ? :D

En vrai, le semver n'a rien à voir avec tout ça. La release 1.0 est un milestone symbolique qui offre une belle opportunité de communication et ils ont bien raison de répéter l'annonce de fonctionnalités qui peuvent intéresser les bidouilleurs!

Et ils doivent même pas forcément être exhaustif, on ne manque pas de respect à ceux qui ont bien raison de pas avoir pris la peine de scruter chaque changelog. Comme expliqué, si une fonctionnalité a déjà été mentionnée dans une mineure précédente Ils ne sont pas obligés de le refaire. Ceux qui sont intéressés d'avoir la liste complète de ce qu'il est possible de faire peuvent aller voir la liste des fonctionnalités actuelles ;)

C'est juste de la communication pour toucher une plus grande audience quoi.

Voilà, sorry pour la boutade en tout cas ;)
Certains reviennent aussi du SemVer, car c'est pas très vendeur commercialement.

Le langage Java par exemple, utilisait au début du SemVer. Java 2, c'est en réalité Java 1.2. etc. Je crois que ça a changé vers Java 5 (où le 5 est véritablement devenu la vraie version de Java, et pas juste 1.5). Mais je ne suis pas spécialiste Java, donc je peux me tromper ^^

Idem avec Firefox. Pendant longtemps, c'était du SemVer. Mais Mozilla a décidé d'utiliser la même pratique que Chrome, car malgré les versions fréquentes, cela donnait un sentiment d'immobilisme (par exemple, la première version de Firefox 3.6 date de janvier 2010 quand la dernière, la 3.6.28 date de mars 2012 soit plus de 2 ans en 3.6.x). Maintenant, c'est un cycle rapide, avec un cycle de quelques semaines seulement.

fdorin

Certains reviennent aussi du SemVer, car c'est pas très vendeur commercialement.

Le langage Java par exemple, utilisait au début du SemVer. Java 2, c'est en réalité Java 1.2. etc. Je crois que ça a changé vers Java 5 (où le 5 est véritablement devenu la vraie version de Java, et pas juste 1.5). Mais je ne suis pas spécialiste Java, donc je peux me tromper ^^

Idem avec Firefox. Pendant longtemps, c'était du SemVer. Mais Mozilla a décidé d'utiliser la même pratique que Chrome, car malgré les versions fréquentes, cela donnait un sentiment d'immobilisme (par exemple, la première version de Firefox 3.6 date de janvier 2010 quand la dernière, la 3.6.28 date de mars 2012 soit plus de 2 ans en 3.6.x). Maintenant, c'est un cycle rapide, avec un cycle de quelques semaines seulement.
On est d'accord. Le SemVer est plutôt adapté pour des librairies. Pour des applications ça perd vite son sens parce qu'on ne souhaite pas essentiellement communiquer sur le côté "rétrocompatible" de telle ou telle fonctionnalité.
A voir la diff avec Momentum (ex Xtrem)
ce que j'aime bien avec le flipper0, c'est qu'ils donnent la part du lion à leur mascotte :3
Fermer